Florian Müllner [Thu, 13 Feb 2025 13:11:04 +0000 (14:11 +0100)]
loginDialog: Show session menu button when in IN_PROGRESS status
Commit c8bb45b added a new IN_PROGRESS status that replaces FAILED
while the user is still allowed to retry authentication.
We need to account for it when updating the visibility of the
session menu button, otherwise the button disappears after
entering a wrong password.
Fixes: c8bb45b41c ("gdm: Limit verification cancellations to be conform to allowed-failures") Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5784
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3638>
Philip Withnall [Tue, 8 Apr 2025 14:32:36 +0000 (15:32 +0100)]
breakManager: Rework notification urgency setting and presentation
Move the setting of the notification’s urgency, and adding the
notification to the queue, to beside where the notification is created.
This avoids the potential for changing the urgency of an existing
notification if none of the branches above are taken, and
`this._notification` is non-empty.
Spotted by Florian Müllner in
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687#note_2405781.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Tue, 8 Apr 2025 14:28:46 +0000 (15:28 +0100)]
breakManager: Clarify some nextBreakType variables
This doesn’t introduce any functional changes, as
`this._manager.currentBreakType` is set to the value returned by
`this._manager.getNextBreakDue()` when entering `BreakState.BREAK_DUE`.
However, it should make the code a little clearer as now the code refers
to the ’next’ break type rather than the ‘current’ one in the context of
an upcoming break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Wed, 2 Apr 2025 11:32:40 +0000 (12:32 +0100)]
breakManager: Update manager state after settings change
The change of settings may have affected when a break is due. In
particular, `this._breakLastEnd` is modified in `_updateSettings()`,
but `this._state` is not modified correspondingly to transition to/from
a `BREAK_DUE` state (if appropriate).
This could be the cause of the `breakDueAgo should be non-negative`
assertion failure from #8280.
Signed-off-by: Philip Withnall <pwithnall@gnome.org> Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Wed, 2 Apr 2025 11:06:42 +0000 (12:06 +0100)]
breakManager: Make brightness setting function clearer
Confusingly, the `brightness` property of
`ClutterBrightnessContrastEffect` has type `CoglColor`, but the
`set_brightness()` setter takes a single `float`.
We previously chose to use the property setter everywhere for
consistency (see
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655#note_2369353),
but didn’t realise the types don’t match.
GJS optimises `this._brightnessEffect.brightness = foo` into a call to
`clutter_brightness_contrast_effect_set_brightness()`, which means the
type mismatch between the two results in a warning (see
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280).
So, let’s change from a property setter into an explicit method call to
avoid the type ambiguity, at the expense of a bit of clarity from using
the same method to set the initial value and each property animation
step.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Wed, 2 Apr 2025 11:05:43 +0000 (12:05 +0100)]
breakManager: Fix a potential null object dereference
There’s no `else` branch above, so it’s possible for
`this._notification` to be `null` at the bottom of the function
(especially if the user has explicitly closed the previous
notification), so handle that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
A type-safe comparision against null can be incorrectly positive with never initialized
variables (undefined).
As spotted in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3688#note_2407551,
allowing for type coercion avoids this situation.
Jonas Dreßler [Wed, 26 Mar 2025 15:12:19 +0000 (16:12 +0100)]
st/image-content: Don't force preferred content size to texture size
When ClutterImage got merged into StImageContent with commit 64d5d01360
("st: Merge ClutterImage with ImageContent"), a small error slipped in when
copying over the update_image_size() function.
Within ClutterImage, update_image_size() served a simple purpose: To call
clutter_content_invalidate_size() in case the texture size would change.
To check that, ClutterImage was storing the existing texture size in the
priv->width and priv->height fields.
When merging into StImageContent, those priv->width/height fields happened
to overlap with priv->width/height of StImageContent, but there they are
storing the preferred size, rather than the texture size. Copying
update_image_size() as-is into StImageContent meant we now set the
preferred size to the texture size, subtly breaking resource-scaled StIcons
(where texture size is a multiple of the preferred size).
The breakage isn't very apparent because StIcons manually set the size
of their internal ClutterActor child to the requested icon-size via
clutter_actor_set_size() in st_texture_cache_load_gicon(), and that makes
the child actor report the correct size in get_preferred_width/height(). The
child actor gets allocated via clutter_actor_allocate_align_fill() from
ClutterBinLayouts vfunc_allocate(), and clutter_actor_allocate_align_fill()
honors both the available size from the parent and the CONTENT_SIZE
request-mode on the child. So when the StIcon has a larger allocation (aka
extra available size), clutter_actor_allocate_align_fill() will fill that
available space with the (too large) content size.
To reproduce the issue, on a resource-scaled monitor, simply create an
StIcon with a fixed width and height that's larger than the icon-size. The
icon will be painted too large and blurry.
Fix this fallout by avoiding to touch the priv->width/height properties on
StImageContent, and instead simply comparing old texture size to new texture
size, we have both textures around after all!
Sebastian Keller [Wed, 26 Mar 2025 10:28:30 +0000 (11:28 +0100)]
loginManager: Use signal argument to detect preparing for sleep
The DBus PreparingForSleep property on org.freedesktop.login1.Manager
does not trigger PropertyChanged signals, leading to wrong values due to
gdbus caching. In most cases it would have always been false.
Additionally it was not included in the XML interface description file
included in gnome-shell. So it was actually undefined.
Since this property is used in _calculateUserStateFromLogind() to
determine that a user is not active when closing the lid on a laptop,
the user was considered still active.
Fix this by storing the "start" argument from the PrepareForSleep signal
instead of trying to read from the property.
Fixes: 6a43b6f55 ("timeLimitsManager: Store screen time state on suspend/resume") Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3679>
Sebastian Keller [Sun, 23 Feb 2025 11:15:52 +0000 (12:15 +0100)]
slider: Align handle size with with pixel grid
Since the handle radius is used to calculate the width and height of the
slider, having the calculated size be a non-integer value can cause the
following widgets in a box-like container to be unaligned with the pixel
grid, which can lead to blurriness or other visual issues.
This for example could be observed with the interface font set to
"Cantarell 12", which results in a handle radius of 8.278. In quick
settings when showing two consecutive sliders, the second slider then
gets rendered at a non-integer vertical offset.
Further having a non-integer size for a StDrawingArea can cause the
texture to get slightly squished or stretched as the size of the cairo
surface is rounded to the nearest pixel, but rendered using the
unrounded actor size.
This commit changes the border radius rather than ceiling the preferred
width/height so that the handle size always matches the width or height
of the widget and there are no visual gaps caused by a partially filled
pixel.
Sebastian Keller [Thu, 20 Feb 2025 22:31:05 +0000 (23:31 +0100)]
slider: Use correct handle size when calculating rightmost position
Using the ceiled radius for calculating the rightmost position the
handle can take on the slider was resulting in a small gap when the size
was not an integer value since the radius used when drawing the handle
is not ceiled.
This effectively reverts 38da479e which seems to have been the wrong fix
for the problem it was trying to solve. The problem presumably had been
caused by not considering the border that the handle still had at that
time.
The border issue was then later fixed by 3ddae9d8, without reverting 38da479e. Then in 6fd0aac8 support for drawing borders on the slider got
dropped, including the changes from 3ddae9d8, leaving us with just the
changes from 38da479e but now without borders on the handle.
Florian Müllner [Sun, 16 Mar 2025 00:57:55 +0000 (01:57 +0100)]
status/bluetooth: Disconnect device signals on destroy
Devices may outlive the corresponding menu item, for example on
shutdown. Make sure that signals are disconnected correctly in
that case to avoid warnings.
Philip Withnall [Wed, 5 Mar 2025 11:32:48 +0000 (11:32 +0000)]
timeLimitsManager: Remove a redundant fallback value
This code was originally copied from `lightbox.js`, where the fallback
is potentially useful because the duration is provided as an argument.
The `timeLimitsManager` uses a constant as the duration, though, so the
fallback is just confusing.
Spotted in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655#note_2369352
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
Philip Withnall [Mon, 3 Mar 2025 18:31:28 +0000 (18:31 +0000)]
breakManager: Switch from lightbox to a Clutter effect for fading out
From some testing on a full session with break reminders enabled, it
seems that it’s possible to break the stacking order of the lightbox
actor if the user continues to interact with the session while it’s
visible (for example, while they’re supposed to be taking a movement
break).
Rather than try and work out what’s going on with the lightbox here, it
seems more robust to switch to using a Clutter effect, like we did with
the screen time UI (in `timeLimitsManager`). Then the effect can be
applied to the main UI group, and doesn’t depend on a separate actor
being placed in the right place in the scene graph.
So, remove the lightbox, and instead add a
`ClutterBrightnessSaturationEffect`, and use its brightness property to
fade the screen slightly while in breaks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
Philip Withnall [Mon, 3 Mar 2025 18:48:10 +0000 (18:48 +0000)]
breakManager: Allow break to be taken or delayed when overdue
This makes the buttons on the ‘break overdue’ notification match those
on the ‘time to take a break’ notification. This makes more sense than
showing no buttons on the former, because it leads on from the ‘time to
take a break’ notification after a short wait.
By adding a ‘Take’ button it gives the user a path to acknowledge that
they are starting to take their break, rather than having to let the
session idle.
The ‘break overdue’ notification wasn’t on the original design[1], which is
probably why its buttons got overlooked.
Philip Withnall [Thu, 20 Feb 2025 17:06:32 +0000 (17:06 +0000)]
timeLimitsManager: Hold inhibitor for sleep to allow saving screen time data
This avoids the race between systemd emitting the `prepare-for-sleep`
signal, gnome-shell then starting to write the screen time data to disk,
and systemd suspending the hardware.
The race isn’t so much of an issue if the suspend succeeds (if
gnome-shell loses, the data will still get written out when the machine
resumes), but it’s slightly problematic if the machine loses power while
suspended, as that means the latest screen time data is lost.
Includes significant suggestions from Florian Müllner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
Philip Withnall [Wed, 19 Feb 2025 15:54:13 +0000 (15:54 +0000)]
timeLimitsManager: Store screen time state on suspend/resume
There are two main changes in this commit:
* Listen to the `prepare-for-sleep` signal from `LoginManager`, which
is emitted just before suspending and just after resuming. When the
signal is received, update the user’s screen time state (active or
inactive), add a transition if necessary, and save the screen time
history if necessary.
* Factor the `preparingForSleep` property of `LoginManager` into the
user’s screen time state, meaning that the user will be considered
inactive between the system going for suspend and coming back from
resume.
The rest of the changes in the commit are boilerplate to allow for this
functionality to be unit tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org> Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
shell/network-agent: Do not query keyring in greeter mode
When trying to connect to a network from gdm, it doesn't make sense to query
secrets from the gdm user since it's a system user.
Furthermore, gdm runs an isolated dbus-session per gnome-shell instance
(for multi-seat setups). Instead, gnome-keyring-daemon is started by systemd
and so it registers on the _main_ dbus session of the gdm user session.
Then, gnome-shell tries to dbus-activate another gnome-keyring-daemon on its
isolated bus, but gnome-keyring-daemon refuses to start as it sees another
instance already running, exposed at $XDG_RUNTIME_DIR/keyring/control.
After a 25s timeout, gnome-shell aborts the request without ever prompting
for a new password.
Because it is both problematic and pointless to query secrets in this case,
let's avoid it altogether and just prompt the user for the network password.
Allan Day [Wed, 19 Feb 2025 14:20:59 +0000 (14:20 +0000)]
data: Reorganize default apps
* Remove obsolete apps
* Add new core apps
* Deduplicate apps which were in both the grid and a folder
* Split system tools out of the utilities folder
* Rearrange the dash a little
projects / gnome-shell.git / log